Every time something goes wrong there will be someone who tries to take advantage of the situation. The recent bushfires in Australia that have killed hundreds of people (the count is not known yet) are a good example. Pastor Nalliah of Catch the Fire Ministries [1] claims that it is due to legalising abortion. This is astoundingly wrong. In a more extreme example representatives of the Westboro Baptist Church were planning to visit Australia to launch a protest in support of the bushfires [2]. I have not yet found any news reports about whether they actually visited Australia or protested - it s most likely that they decided not to visit due to the Australian laws being very different to US laws regarding the relative importance of freedom of speech and incitement to violence. Apparently the insane Westboro Baptist Church people (who are best known for GodHatesFags.com and GodHatesAmerica.com) believe that God hates Australia and caused the fires (presumably due to Australia not persecuting homosexuals). Danny Nalliah has permanently damaged his own reputation by acting in a similar way to the Westboro Baptist Church. The reputation of Catch The Fire now depends on how quickly they get a new pastor Please note well that the vast majority of Christians have nothing in common with Westboro or Catch The Fire. I don t recall the last time I met an Australian Christian who was strongly opposed to homosexuality or abortion. Now we do have to try and investigate ways of avoiding future tragedies, and the work to do this needs to begin immediately. John Brumby (the Premier of Victoria) has announced that Victoria will get new strict building codes for fire resistant buildings [3]. There have been many anecdotes of people who claim to have been saved by attaching sprinkler systems to their homes, by building concrete bunkers to hide in while the fire passes, and using other techniques to save their home or save themselves. Some more research on the most effective ways of achieving such goals would be worthwhile, an increase in funding for the CSIRO to investigate the related issues would be a good thing. The article also has an interesting quote As the fallout from the disaster widened, the union representing the nation s 13,000 firefighters warned both the federal and state governments to take global warming seriously to prevent a repeat of last weekend s lethal firestorm . However given that traditionally Australia and the US have been the two nations most opposed to any efforts to mitigate global warming it seems unlikely that anything will change in this regard in a hurry. The attempts to link bushfires to abortion and homosexuality are offensive, but can be ignored in any remotely serious debate about politics. However there are some other groups trying to profit from the tragedy that make claims which are not as ridiculous. On the 9th of February the Australian Green party was compelled to release an official statement from Spokesperson Scott Ludlam, Sarah Hanson-Young, Rachel Siewert, Christine Milne, and Bob Brown following some political discussion about Greens policies [4]. There have been attempts to blame the Greens for the tragedy which were politically motivated, some of which came from groups that traditionally oppose the Greens for other reasons (I m not going to provide the detail - anyone who is really interested can do google searches on the people in question). On the 16th of February Bob Brown (the leader of the Green party) felt obliged to make another media release reiterating the fact that the Greens support prescribed burn-offs to limit the scope of wild fires [5], he also decried the hate mongering that has been occurring in the wake of the disaster. One of the strange memes that seems to be spread by opponents to the Greens is that the Greens are all supposedly from the city and know nothing about the country. To avoid being subject to such attack I feel obliged to note that on one of the bad fire days I visited my parents. I spent the morning with my father and some friends at a park that was not far from the fire area, my friends then returned to their home which was not far from the fire area. I then had lunch with my parents and watched the smoke through the dining room window. After that my friends didn t respond to email for a while and I was concerned that they may have lost their house or maybe suffered injury or death. I didn t know them well enough to feel it appropriate to try a dozen different ways of contacting them (I m sure that many other people were doing so), but I was rather concerned until my wife received an email from them. But I don t base my political beliefs on what I personally observe or my connections to people on the edge of the fire zone. I believe in the Green principles of Peace and Non Violence, Grassroots Democracy, Social and Economic Justice, Ecological Sustainability and the use of science and statistics to determine the best ways of achieving those goals.

• [1] http://www.livenews.com.au/articles/2009/02/11/Bushfires_caused_by_abortion_laws_Pastor_claims


• [2] http://www.news.com.au/story/0,27574,25067362-2,00.html


• [3] http://www.theage.com.au/national/never-again-brumby-20090211-84sv.html?page=-1


• [4] http://greensmps.org.au/content/time-heal-our-communities


• [5] http://greens.org.au/node/5229

Some months ago, I got a phone call from Rafael Fern ndez Flores. He wanted to interview me for a book he was working on regarding the history of computers in Mexico. The first computer in Latin America was installed in 1958 at my University (UNAM), and last year there were several activities conmemorating it. One of said activities is the publication of the book Historias de la Historia del c mputo en m xico, by Rafael Fern ndez and Margarita Ontiveros.
The book was printed in November, and Rafael gave me my copy in early December. It is quite an entertaining read - I mostly enjoyed the archaeological parts of it, referring to the 1950s and 1960s, and with many people that I know first hand (as my father is one of the founding researchers of the Centro de Investigaci n en Matem ticas Aplicadas, Sistemas y Servicios, CIMASS, now IIMAS).
I do believe, anyway, the book is focused too heavily on what happened in the large-scale computer world during a fundamental point in time for me (late 1970s, early 1980s) - It shows that the authors were very involved in the important projects the University set foot on, but they overlook fundamental pieces of the history. Very important developments were made in smaller venues (it was shocking for me to find only one mention, and just as a reference, to Fundaci n Arturo Rosenblueth and its great Centros Galileo, where many hundreds of kids (me included) learned to love computers, to program, and had a thriving socialization place. I also missed mentions of the BBS scene in Mexico, for which there are various exponents. And, just to single out one person, I found it absurd to have me interviewed and not to include La Mancha de la Calabaza que Ladra.
One of the last chapters -there are over 40 chapters, stemming from over 30 individual interviews- publishes the talk I had with Rafael. I must say there are small errata in its transcription (the first example that comes to my mind: I told him that one of the fruits of the OLPC project was the appearance of the now-popular netbooks, partly due to the appearance of lower cost parts, but I must reiterate I didn't say the Asus EEE is a part of said project). You can I am attaching my interview (as scanned, low-res images) to this post, in case you are interested.
Anyway - If the topic interests you, you will find many interesting passages, many passages you will surely laugh with and probably remember. The book is very well laid out. And it is a great joy to be part of it!

(this is something I've had "in production" for many months now, I just haven't had the time or energy to do a proper write up about what I did) We have a cat water bowl, it looks like this: Under "normal" circumstances, it usually lasts about seven days. So when our weekly routine is happening, we'll refill it on a Saturday whilst doing house chores, and it'll last until the following Saturday when it gets refilled. Unfortunately, sometimes our routine gets disrupted, and we forget. Sometimes, we travel and have a house-sitter, who may not pay as close attention to such things as ourselves. Once, one of our cats was licking the condensation off a chilled bottle of soft drink that was on the kitchen counter one evening, before we realised the water bowl needed refilling. Naturally, we felt like terrible pet owners. So I think it was some time around the 2008 Maker Faire, that I hatched the idea of having some sort of water sensor on the cat bowl, which would communicate to one of the various computers in house. At the Maker Faire, I bought a copy of Making things talk, and an Arduino starter kit, which consisted of a Diecimila board and a make-it-yourself proto shield. I also bought a little electronics starter kit, which consisted of a breadboard and various components, and a USB-TTL cable. I decided to use Bluetooth to communicate with the board, as I already had my MythTV setup using a Bluetooth keyboard and mouse, and it was within range of the water bowl. I decided against using Zigbee, because I didn't know anything about it, and I didn't want to add (or learn about) yet another wireless infrastructure just for this project. I should point out that I know very little about electronics. I'd never owned (or really used) a soldering iron until I embarked on this project. I took a basic soldering class at the Tech Shop, but I'd already assembled the proto shield by the time I took the class, so I'd pretty much figured it out. I had a very naive vision that I could just basically shove two wires in some water and it'd close a circuit and that would be my water sensor. Of course this didn't work, so I started hunting around on the Internet for a circuit that would do this. I happened upon a circuit (I don't seem to have retained the URL, so I can't link to it), which just consisted of a couple of transistors and some resistors. So I headed off to Fry's to try and buy the transistors I needed. I quickly discovered that I didn't have sufficient information to identify the transistors that I wanted, but I did happen to stumble upon a cheap assemble-it-yourself water alarm. It consisted of a PCB, and a transistor and some resistors and a buzzer. I bought a couple of these instead. Between studying the PCB and the circuit diagram that came with the alarm, I was able to reproduce it on my breadboard instead of on the PCB. Sure enough, placing the two probes in water closed the circuit. I replaced the buzzer with an LED so I could see what was going on. I attached the circuit to the Arduino proto shield, and had it feed into one of the digital I/O ports. I wrote some quick and dirty Wiring code so that when water not present (i.e. the circuit was open and no current was detected on that I/O port) the LED was switched on. Really at this point, I didn't need a microcontroller, I could have presumably achieved the same thing with a NOT gate. At this point, I wanted to make the sensor remotely queryable. I bought a BlueSMiRF Silver Bluetooth modem, which I attached to the TX and RX lines of the board (I first configured it by attaching the USB-TTL cable to it and using Minicom on my laptop). I extended the Wiring code to provide a rudimentary prompt, and accept a command to check if water was present. I think around this time it also dawned on me that I could use the digital I/O pins as a switch. When they're "high" they provide power. So rather than constantly running a current through the water, I only needed to briefly power up the water detection circuit, see if the circuit closed or not, and then report if water was present if it did. I much preferred this, as at the time, I was endeavouring to power the whole sensor off a 9 volt battery. I figured I'd get much better battery life if I wasn't running a current through the water the entire time. I should point out that I did some "tongue tests" in a glass of water while the circuit was powered up, and couldn't detect a difference between when the circuit was on or off. The last thing I wanted to be doing was zapping the cats! At this point, the Wiring and Arduino work was pretty much complete. I setup ser2net on the MythTV server, so that I could just connect to port 4000, and be connected to the water sensor.

apollock@icarus:~$ telnet teevee 4000
Trying 172.16.0.9...
Connected to teevee.andrew.net.au.
Escape character is '^]'.
ser2net port 4000 device /dev/rfcomm0 [9600 N81] (Debian GNU/Linux)
waterbowl> s
Water is present
waterbowl>
telnet> q
Connection closed.
apollock@icarus:~$

The Wiring code running on the Arduino board is checked in here. Next, I wanted to monitor this with Nagios. One thing I found with the Bluetooth connection was that it wasn't all that reliable. Not every connection to port 4000 resulted in a connection with the water sensor. I elected to write some standalone code that submitted results to Nagios by way of a passive check, rather than having Nagios try to actively monitor it. Again, trying to conserve energy, I decided to only check the sensor once every 8 hours. So I wrote a Python daemon, which tried to be as robust as possible. If at first it doesn't make a connection on its 8 hourly schedule, it keeps trying until it does. Nagios itself has some freshness detection for this monitor, so if no passive result is submitted within 8 hours and one minute, Nagios alerts that something is possibly wrong with the sensor itself. (The original intent was to deal with the situation where the battery went flat) This is the Nagios service definition I've got. Some of it may be unnecessary or redundant:

define service  
        host_name                       teevee
        service_description             Cat water bowl
        check_command                   check_stale!2!"Check water bowl monitor is on and reachable"
        normal_check_interval           480
        notification_interval           240
        active_checks_enabled           0
        check_freshness                 1
        freshness_threshold             28860
        max_check_attempts              1
        check_period                    24x7
        use                             generic-service
        stalking_options                o,w,c
        contact_groups                  everyone
 

The code for the Python daemon is checked in here. So everything was going swimmingly, apart from I couldn't get even 24 hours of monitoring on my conservative 3 times a day schedule, and the Bluetooth modem configured for all of its power saving options, and the water sensor itself only being powered on when it was performing a check. There wasn't much more I could do to try and reduce power consumption, at least with my limited electronics knowledge. Perhaps using Zigbee instead of Bluetooth would have helped, but I still think I'd have been going through 9 volt batteries more quickly than I'd have liked. I also had a brief foray into solar powering the board. I thought maybe the lighting in the house would be sufficient to power the board. Of course this didn't work out. I'd also have needed to make the code running on the board more self-sufficient, and have it just provide a water status indication whenever it had enough power to do so, instead of being a fairly dumb device like it currently is. This all felt a whole level more complicated, and out of my league, and I wasn't interested in attempting this sort of remote-sensing exercise at this time. The Arduino board can also be powered by USB, so as I already had some long USB type A to type B cables (that had funky lights in them to boot), I decided to just get a wall wart that had a USB type A receptacle, and powered the Arduino board that way. So much for being completely "wireless". (I could have also gotten a general purpose DC power supply that was capable of spitting out 9 volts, but I doubted I'd get one with a sufficiently long cable, which is why I went for the USB-powered option, as I already had a cable long enough) Speaking of wires, the most challenging part was the probes for the water sensor. As they were going to be permanently in the cats' drinking water, I didn't want to contaminate the water with them. I figured plain untinned copper wire would be okay, since water pipes are copper. Finding untinned, unstranded copper wire was a real challenge. I started out using some FM antenna cable, but that was stranded, and the shielding was a nightmare to strip. It was also reasonably difficult to make go where I wanted it. What I really wanted was something more solid, that would flex and stay where I put it. I cannibalised a spare IEC power cable, but it was also stranded copper wire. I finally managed to obtain some solid-core CAT-5 cable from a hardware store, and this has worked exactly as I wanted. I haven't done any further work on the setup since getting the CAT-5 cable for the probe. Further improvements that I'd like to do at some point:

• transfer the circuitry from the breadboard to a breadboardless proto shield, and generally try to house the sensor better
• find a better way of connecting the probe wires to the circuit, so it's easier to remove the monitor when refilling the water tank (currently the CAT-5 wires are just shoved into the breadboard). The whole thing is barely spouse-approved as it currently is, let alone being easy enough for an untrained house-sitter to try and negotiate
• integrate with Asterisk so a house-sitter gets a telephone call when the water bowl needs refilling

I had a lot of fun with this project. I had a real sense of achievement, being able to go from concept to completion, and learn a few things about electronics along the way. I'm normally not a fan of messing around with hardware. Some photos of the project are here.

From the “Software that recently rocked my pants” department:

• Bitlbee: talk to your Jabber/MSN/Yahoo contacs with your IRC client. I was aware of its existance, never found the time to start using it. Shame on me! I run it on my laptop rather than on a server.
• Matplotlib: plotting library for Python, and I find the results very pretty. Looks quite powerful, though I had slight problems figuring out how to do certain stuff.
• Schroot with LVM: brilliant, particularly if you make use of sessions.
• KVM with libvirt and virt-manager: seems to work well, almost as easy as VirtualBox, and (tada!) thanks to VNC you get detaching for your guests (no more Windows reboots if you restart your Xserver).

I also thank Martin F. Krafft for helpfully updating the encryption howto I followed for my previous laptop to mention that using a single encrypted device and LVM on top of it is (possibly) preferred nowadays. And to Simon McVittie for his idea of a small unencrypted Debian installation for recovery purposes in laptops without an optical drive. P.S.: I can’t believe this shit about blogging every day in November.

One thing I had wondered was why home air-conditioning systems are more efficient than air-conditioning systems for server rooms. I received some advice on this matter from the manager of a small server room (which houses about 30 racks of very powerful and power hungry servers). The first issue is terminology, the efficiency of a “chiller” is regarded as the number of Watts of heat energy removed divided by the number of Watts of electricity consumed by the chiller. For example when using a 200% efficient air cooling plant, a 100W light bulb is rated as being a 150W heat source. 100W to Heat it, 50W from the cooling plant to cool it. For domestic cooling I believe that 300% is fairly common for modern “split systems” (it’s the specifications for the air-conditioning on my house and the other air-conditioners on display had similar ratings). For high-density server rooms with free air cooling I have been told that a typical efficiency range is between 80% and 110%! So it’s possible to use MORE electricity on cooling than on running the servers! One difficulty in cooling a server room is that the air often can’t flow freely (unlike a big open space such as the lounge room of your house). Another is the range of temperatures and the density of heat production in some parts (a 2RU server can dissipate 1000W of heat in a small space). These factors can be minimised by extracting hot air at the top and/or rear of racks and forcing cold air in the bottom and/or the front and by being very careful when planning where to place equipment. HP offers some services related to designing a server room to increase cooling efficiency, one of the services is using computational fluid dynamics to simulate the air-flow in the server-room [1]! CFD is difficult and expensive (the complete package from HP for a small server room costs more than some new cars), I believe that the fact that it is necessary for correct operation of some server rooms is an indication of the difficulty of the problem. The most effective ways of cooling servers involve tight coupling of chillers and servers. This often means using chilled water or another liquid to extract the heat. Chilled water refrigeration systems largely remove the problem of being unable to extract the heat from the right places, but instead you have some inefficiency in pumping the water and the servers are fixed in place. I have not seen or heard of chilled water being used for 2RU servers (I’m not saying that it doesn’t get used or that it wouldn’t make sense - merely that I haven’t seen it). When installing smaller servers (2RU and below) there is often a desire to move them and attaching a chilled-water cooling system would make such a move more difficult and expensive. When a server weighs a ton or more then you aren’t going to move it in a hurry (big servers have to be mostly disassembled before the shell can be moved, and the shell might require the efforts of four men to move it). Another issue related to water cooling is the weight. Managing a moderate amount of water involves a lot of heavy pipes (a leak would be really bad) and the water itself can weigh a lot. A server room that is based around 20Kg servers might have some issues with the extra weight of water cooling (particularly the older rooms), but a server room designed for a single rack that weighs a ton can probably cope. I have been told that the cooling systems for low density server rooms are typically as efficient as those used for houses, and may even be more efficient. I expect that when designing an air-conditioner the engineering trade-offs when designing for home use favor low purchase price. But someone who approves the purchase of an industrial cooling system will be more concerned about the overall cost of operations and will be prepared to spend some extra money up-front and recover it over the course of a few years. The fact that server rooms run 24*7 also gives more opportunity to recover the money spent on the purchase (my home A-C system runs for about 3 months a year for considerably less than 24 hours a day). So it seems that the way to cool servers efficiently is to have low density server rooms (to the largest extent possible). One step towards this goal would be to have servers nearer the end users. For example having workgroup servers near the workgroup (instead of in the server room). Of course physical security of those servers would be more challenging - but if all the users have regular desktop PCs that can be easily 0wned then having the server for them in the same room probably doesn’t make things any worse. Modern tower servers are more powerful than rack mounted servers that were available a few years ago while also being very quiet. A typical rack-mounted server is not something you would want near your desk, but one of the quiet tower servers works quite well.

• [1] http://en.wikipedia.org/wiki/Computational_fluid_dynamics

Share This

This is part 1 of a series on articles about the Firewire security issues mentioned below. For many years now, attacks via Firewire / i.LINK / IEEE 1394 have been a known security issue. Basically, if you gain physical access to a PC or laptop which has Firewire ports (or PCMCIA/Cardbus/ExpressCard, more on that later) you can

• read arbitrary RAM contents from the victim's system,
• overwrite arbitrary RAM contents with whatever you want,
• and perform many, many severe attacks based on the two issues above. Examples include grabbing a full RAM dump via Firewire (takes only a few minutes), grabbing ssh-agent keys, grabbing screen contents, modifying screen contents, bypassing login/password screens, and many, many more...

All of this is done by exploiting a "feature" of the Firewire spec (OHCI-1394) (PDF), namely that it allows read/write access to physical memory (via DMA) for external Firewire devices. Worse, as this is DMA, the CPU/OS will not even know what's going on. Even worse, this works regardless of whether you have locked your screen with a password-protected screensaver, or xlock, or vlock, or whatever. As long as the system is running, you're vulnerable. In this article, I intend to give a fairly complete overview of the available papers published on this issue, tools for testing the attacks, as well as mitigation techniques for various OSes. If I'm missing some important papers or tools, please post a comment! Papers, Attacks, and Tools Over the years a number of presentations and papers have been released with information about these Firewire issues. Maximilian Dornseif et. al. The first publication that I know of was done by Maximilian Dornseif, Michael Becher, and Christian Klein. They gave a number of talks on various security conferences on this topic:

• Pacsec 2004: 0wned by an iPod (PDF)
• 21C3: Hacking with Fire / Feuriges Hacken - Spa mit Firewire (PDF)
• Cansecwest 2005: Firewire: all your memory are belong to us (PDF)

They also released a number of tools, Firewire libraries for Mac OS X and Linux, as well as small demo scripts which use those libs:

• pyfw-20041111.tar.gz: Mac OS X Firewire bindings for Python, various demos
• http://c0re.23.nu/c0de/pyfw/: Other versions of the above code
• pyfw_linux.tar.gz: Linux Firewire bindings for Python (can be used with above demo code on Linux)
• ipod-linux-pyfw.tar.bz2: Instructions (+ disk image) on how to turn your iPod into a Firewire attack tool

Adam Boileau In 2006 Adam Boileau (a.k.a. Metlstorm) gave a talk called Hit by a Bus: Physical Access Attacks with Firewire (PDF) at Ruxcon 2006. In 2008 he then released a set of tools:

• pythonraw1394-1.0.tar.gz: Python bindings for libraw1394 (Linux). Tools: businfo, romtool, 1394memimage
• winlockpwn: Python script which can circumvent a locked Windows XP screen (an arbitrary password will log you in)
• bioskbsnarf: Grabs/shows the BIOS keyboard buffer via Firewire (which often contains your BIOS password)

Peter Panholzer As of early 2008 Peter Panholzer from sec-consult.com published a two-page whitepaper which says they were able to run a winlockpwn-like attack on Windows Vista via Firewire. There's not much information in the PDF unfortunately, and no tools were released, as far as I know.

• Whitepaper: Physical Security Attacks on Windows Vista (PDF)
• Bugtraq Thread about the whitepaper

David R. Piegdon The most recent toolset and papers I know of are from David R. Piegdon (a.k.a. IosTrace), who gave a number of talks in 2007/2008 about the issue, and also released a toolset called SEAT1394.

• 2007: OpenChaos: hacking in physically addressable memory (no extra slides)
• Easterhegg 2008: FireWire Hacking: paper (PDF), slides (PDF)
• More papers here...
• http://0null.net/software/SEAT1394/: tools and libraries for pyhsical memory access via Firewire/DMA: 1394csrtool, liblinear, libphysical, debug-sshkey, dump-memory, remote-ps, show-stack, snarf-sshkey, test-all-pagedirs, dmashell, ...

I'll go into much more detail on how the tools are used and what they can do in another follow-up article. Mitigation There are ways to eliminate or at least mitigate these attack vectors. The simplest and most secure way is to not have any Firewire ports installed (don't put Firewire PCI/PCIe cards in your PC, don't use Firewire PCMCIA/Cardbus/ExpressCard cards). Now, if you have a laptop with built-in Firewire ports, you have a problem, of course. In that case you could still physically destroy the port (by opening the laptop and cutting/desoldering stuff, or by putting glue/epoxy in the port in order to prevent any Firewire cables being attached). These are slightly drastic (but effective!) measures. Note: Even if you don't have any Firewire ports, you're not automatically safe and secure. If your laptop has a PCMCIA/Cardbus/ExpressCard slot, an attacker can simply insert a PCMCIA Firewire card (for instance) in that slot. Chances are, that your OS will automatically load the driver for that card and also the Firewire drivers you'll need if you want to use the card for attaching Firewire devices. Game over. Your "secure" laptop is now vulnerable... If you cannot (or don't want to) remove/destroy/disable your Firewire ports, the next best thing is to ensure that nobody except yourself ever gets physical access to your PC/laptop. This is hard to do for a PC, and almost impossible for a laptop, mind you. Finally, there are some software measures you can use to prevent at least physical DMA access for Firewire devices: Mitigation: Linux Pretty much every Linux system with the "old" Firewire drivers loaded (kernel module ohci1394 et. al.) is vulnerable to these issues. Newer kernels now also ship with a new Firewire stack called "juju" (kernel module firewire_ohci et. al.) which may or may not have the same issues (not fully tested by me so far, will report back later). Per default, all recent kernels, e.g. 2.6.26, are vulnerable, but see below. Under Linux, simply using a kernel which doesn't have any Firewire support (neither built-in, nor as a module) is the most secure option. If you must have Firewire support you can load the ohci1394 module with the phys_dma=0 parameter to at least disable physical DMA support:

  $ modprobe ohci1394 phys_dma=0

I have personally tested this on some boxes and I can confirm that it renders the currently published tools useless. As for the new "juju" Firewire stack, I'm not so sure. A few quick tests showed that the currently available tools don't work with the new stack, but you shouldn't feel too secure! AFAIK the new stack does support (or will support soon) physical DMA for Firewire, so it's probably just a matter of adapting the tools a bit (I'll do some testing/research on this later, as time permits). Mitigation: Mac OS On Mac OS you might also be able to completely remove Firewire support from the kernel (but I don't know if/how that can be done, not sure if you can easily recompile Mac OS kernels, and/or if you even have buildable source code and toolchains for that). However, you can at least remove the Firewire support in the default Mac OS installation by unloading AppleFWOHCI.kext:

  $ sudo kextunload /System/Library/Extensions/IOFireWireFamily.kext/Contents/PlugIns/AppleFWOHCI.kext

Thanks to a Daniel Reutter for letting me abuse his MacBook via Firewire and for finding the above kextunload command line. We have successfully tested that after unloading AppleFWOHCI.kext the current tools won't work anymore. The tests were done on a Mac OS X Tiger (I think) with all recent security updates applied. Please leave a comment if you can test other versions of Mac OS X... Mitigation: Windows As for Windows, well, I guess you're screwed. While Windows XP does implement sort of "protection" in that it only allows physical DMA access via Firewire to devices which "deserve it", e.g. iPods (or any other Firewire mass storage device, I guess) this can be easily defeated by having your attack PC/laptop pretend to be an iPod (see the romtool Python script by Adam Boileau). The only remaining option I know of (short of removing/destroying Firewire ports or preventing physical access alltogether) is to disable the Firewire ports/drivers in the device manager (untested by me so far). If you do that, remember to also disable all PCMCIA/Cardbus/ExpressCard controllers, of course (see above). So far I've tested Windows XP SP2/SP3 successfully with Adam Boileau's tools. I haven't yet been able to test Windows 95/98/Vista, if you can verify one of them, please leave a comment. Mitigation: OpenBSD/FreeBSD/NetBSD/OpenSolaris/... On OpenBSD you're likely not vulnerable as OpenBSD doesn't have any Firewire drivers at all, as far as I know ;-) As for FreeBSD, NetBSD, OpenSolaris, and other OSes I don't have any information. I might be able to test one or two of them in the nearer future, but please leave a comment if you have some information about whether they are vulnerable and/or how you can secure your system... Conclusion That's it for now. I hope you now have a good overview of these issues and how to protect. I can only urge you to take this problem seriously! Three or four minutes of leaving your laptop unattended are fully sufficient for an attacker to get a full forensic image of all your RAM contents for later analysis. This is at least as critical as the Cold Boot attacks, if not worse. I will follow-up with more articles about some more interesting details on these Firewire issues, how to use the above tools, and I'll report on some of the stuff I was able to find in RAM dumps gathered via Firewire...

Ryan kindly sent me a copy of the ACPI tables for his motherboard, so I've had the opportunity to look at them in a little more detail. There's nothing especially surprising. The first method of interest is OSFL, which I've annotated below:

   Method (OSFL, 0, NotSerialized)
     
        If (LNotEqual (OSVR, Ones))
         
            Return (OSVR)
         

This block simply skips the checks if they've already been evaluated and returns the cached value

        If (LEqual (PICM, Zero))
         
            Store (0xAC, DBG8)
         

If the programmable interrupt controller has been set up in PIC mode rather than APIC mode, 0xAC is written to i/o port 0x80. This would then show up on a plug-in card if one were attached. Simply debug code

        Store (One, OSVR)

Set OSVR to 1, which in this case clearly means "Unknown OS"

        If (CondRefOf (_OSI, Local1))

This checks whether the OS supports the _OSI method. If it does, the following block is executed. If not, the older _OS method is used to detect the OS

         
            If (_OSI ("Windows 2000"))
             
                Store (0x04, OSVR)
             

Newer versions of Windows will also claim to support the interfaces defined in older versions, so this set of checks is done in release order

            If (_OSI ("Windows 2001"))
             
                Store (Zero, OSVR)
             
            If (_OSI ("Windows 2001 SP1"))
             
                Store (Zero, OSVR)
             
            If (_OSI ("Windows 2001 SP2"))
             
                Store (Zero, OSVR)
             
            If (_OSI ("Windows 2001.1"))
             
                Store (Zero, OSVR)
             
            If (_OSI ("Windows 2001.1 SP1"))
             
                Store (Zero, OSVR)
             
            If (_OSI ("Windows 2006"))
             
                Store (Zero, OSVR)
             

If we've got this far, OSVR is now set to 0. Linux will claim to support all of these interfaces, and so OSVR should be 0 on Linux systems. Note that there is no _OSI check for Linux - the 2.6.24 change to remove Linux from the set of claimed interfaces is therefore irrelevant

         
        Else
         

Linux supports _OSI, so we should never be here. But if we somehow are...

            If (MCTH (_OS, "Microsoft Windows NT"))
             
                Store (0x04, OSVR)
             

Linux has responded to _OS with "Microsoft Windows NT" since 2.6.9. MCTH is simply a string matching routine defined elsewhere in the DSDT. So, worst case here is that OSVR is 4

            Else
             
                If (MCTH (_OS, "Microsoft WindowsME: Millennium Edition"))
                 
                    Store (0x02, OSVR)
                 
                If (MCTH (_OS, "Linux"))
                 
                    Store (0x03, OSVR)
                 

..because this could never be true unless you're running 2.6.8.1 or earlier. But even so, getting here would still indicate failure - we've supported _OSI since before then, and so should never come anywhere near this code block.

             
         
        Return (OSVR)
     

In summary, we end up with the following values:

Value	OS
0	Windows XP, 2003 or Vista. Linux (assuming absence of bugs)
1	Unknown OS
2	Windows ME
3	A version of Linux that doesn't implement _OSI and is from before 2.6.9
4	Windows NT 4 and 2000. A version of Linux that doesn't implement _OSI and is 2.6.9 or later (I don't believe any such version exists

Now, where is this used? The majority of the OSFL checks only check whether the return value is 1 or 2, which will only be true for an OS that (a) doesn't claim to be Windows or (b) is Windows ME. Linux doesn't fall into either of these categories, so we can ignore them. The first interesting hit we have is in the HPET code, where _STA will return 0xf (device present and working) if OSFL is 0 and 0xb (device present and working, but should not be shown in the UI) otherwise. This is just to keep the HPET from showing up in versions of Windows that don't know what it is. The only other interesting hit is the following code from the PCI bus initialisation pathway:

 
                               If (LEqual (OSFL (), Zero))
                                 
                                    Store (0x59, SMIC)
                                 
                                Else
                                 
                                    If (LEqual (OSFL (), 0x04))
                                     
                                        Store (0x5A, SMIC)
                                     
                                    Else
                                     
                                        Store (0x58, SMIC)
                                     
                                 

This writes different values to SMIC (which turns out to be i/o port 0xb2) depending on the OS. 0xb2 is the standard(ish) way to trigger a system management interrupt, which causes the CPU to execute some code from a memory region that can't be accessed by the OS. This isn't that unusual, but it's a little weird. In any case, note that there's no check for whether OSFL is 3 here (which would be true if the _OS call returned Linux), and so Linux is being treated identically to Windows ME and any unknown OS. In reality, Linux will be treated identically to either Vista or 2000. This block provides no evidence of conspiracy. Finally, the OS version flag is written to a region of memory before suspend and read back afterwards. Nothing appears to be done with this information - it's conceivable that the low-level resume code in the BIOS has conditionals based on this, but I suspect that it's just boilerplate code that's ignored.

To summarise:

• There is no code in this DSDT that could determine that the system is running any Linux kernel of 2.6.9 or later. This may even be true of earlier versions - I'm not sure when _OSI support was added
• Even if the code did manage to determine that the system was running Linux, there are no codepaths that are Linux specific. Every piece of code is run on at least one version of Windows

What's the problem, then? I've no idea. The only "significant" issue is that the OEMB table provided by the BIOS has an incorrect checksum. Given that the OEMB table is never used by Linux (it's a vendor extension of some kind, with the best hint I've been able to find being that it can be used to pass information from the BIOS to the OS - kind of like the rest of ACPI, then...), this is pretty unimportant. And given that the OEMB table isn't part of the ACPI spec, it's certainly entirely irrelevant when it comes to determining whether the system is ACPI compliant or not.

Are there ACPI issues with Ryan's system? It sounds like it. The "Error attaching device data" complaints indicate some kind of failure on the part of the kernel to work out how the devices correspond to the ACPI namespace, but I strongly suspect that this is a Linux bug. Failure to reboot after suspend? Could be anything (I'd need direct access to the hardware to figure it out properly), but again it's almost certainly a Linux bug. The standard way Linux reboots systems is to bang the keyboard controller, and it's conceivable that something we're doing on resume is leaving the keyboard controller in a slightly confused state. We're clearly doing something wrong there, given that my Dell comes up without a keyboard about one resume in twenty - I just haven't had time to look into it yet.

The only remaining thing is the mutex handwaving. I've got no clue what's going on there. Ryan's suggested change (from Acquire (MUTE, 0x03E8) to Acquire (MUTE, 0xFFFF)) simply means that the OS will wait forever until it acquires the mutex - in the past it would only wait a second. The reason the compiler generates a warning here is that the firmware never checks whether it acquired the mutex or not! Bumping the timeout to infinity obviously fixes this warning (there's no need to check the return code if you're happy to wait forever rather than failing), but the original code is merely stupid as opposed to a spec violation.

Take home messages? There's no evidence whatsoever that the BIOS is deliberately targeting Linux. There's also no obvious spec violations, but some further investigation would be required to determine for sure whether the runtime errors are due to a Linux bug or a firmware bug. Ryan's modifications should result in precisely no reasonable functional change to the firmware (if it's ever hitting the mutex timeout, something has already gone horribly wrong), and if they do then it's because Linux isn't working as it's intended to. I can't find any way in which the code Foxconn are shipping is worse than any other typical vendor. This entire controversy is entirely unjustified.

(Playing Kraftwerk - The Telephone Call.) Warning: This is a long-wound complaint post. The only reason this is going to the Planet is because I have no method yet of disabling individual posts for syndication. Please skip, with my apologees for the noise, if you don’t want to listen to complaining. May contain nuts. May drive you nuts. Drove me nuts. Mmm, pistachio. When I was around 11, I got my first cellphone. I was very proud. This was back when being 11 and having a cellphone was a real novelty; pagers were still being sold, and the NMT network was still running. Like many things I appreciate, I found it in a dumpster. It was ancient, even then: a Motorola MicroTAC brick, missing its antenna. I borrowed one of my grandmother’s hairpins, and voila, working phone - as long as you didn’t leave Oslo. It had a certain cyberpunk look to it, even then: I loved it. I remember that I first bought a NetCom pay-as-you-go card; I don’t quite remember the number, but it had “283″ in it at the end, if you want to wardial. For some reason, Dad needed a SIM card so I gave him mine. So I bought myself a new one, a Telenor card, pay-as-you-go, number 91 85 95 08. I must have been around 12 at the time. And that number served me very well. Fast-forward 6 years, to late March, 2006. I had just turned 18, and one of the first things I wanted to do was get a massively cheaper, proper subscription. I’d been procrastinating it for a bit - as I am wont to - but when a nice gentleman at the subway station told me about a nice new company called SEA Norway and their wonderful prices, I accepted. Big mistake. Here begins the saga of woe… For a good while, I was very happy with their service - even though GPRS data never worked, I never used it anyway. Their name changed to Vitel somewhere along the way. I received a phone call from an enthusiastic salesman who told me how much cheaper Vitel’s power subscription is. It seemed very reasonable, so I went for it. One of the arguments he gave me was that I could collect all those utilities into one bill. I told him that I couldn’t have this: Since I’m a live-alone student, my power bill is covered entirely by the city council, so I need a proper bill to hand over every month. “Sure, that’s no problem”. I check and double-check that, and I stress it. Sure, no problem. OK, deal. Big, big mistake. They draw 2700 Kroner from my account, using the automated pay system (AvtaleGiro) that I had set up for the phone bill. 2700 Kroner (530 US Dollars) is a lot of money, especially when your monthly income, 5000 Kroner (1000 US Dollars) barely covers the necessities. So I cancel the autopay system. (I still have not received that money!) 23rd of January, my subscription is cut, since I hadn’t paid the bill. They hadn’t mailed it to me, and I’d told them I’d cut the AvtaleGiro, but I simply did not receive the bill. So I call them up in February some time and try to figure out a solution. “You didn’t pay the bill, so the subscription is closed.” -”So if I pay the bill, will you reopen it?” -”No, sorry. It is closed now.” -”So then I’ll have to transfer the number to another provider?” -”No, you can’t do that; it’s closed now.” -”You can’t refuse to transfer the number, that’s simply not legal.” -”Sure it is, the subscription’s been closed.” Urgh. So some time in the middle of March, before The Gathering, I call NetCom up: I want to transfer my number to them, please. Sure, no problem. No, this number is registered as active in our system. All is well. We’ll make the switchover on March 28th, and you will get your SIM card in the mail: It should be in your box by then. Fantastic! The 28th of March came and went with no great ceremony, not even a SIM card. No switchover occurred. I give them the benefit of the doubt for more than a fortnight. Some time in April, then, I get sufficiently annoyed to call them up and ask what had happened. “Oh, no, it seems Vitel is using the old transferral system”. -”OK?” -”Yes, you will have to send us a form with your signature by fax to carry this transfer out.” -”Sigh, alright. Where can I get this form?” -”I’ll email it to you.” Great. So I get the form. May was very busy, so I didn’t get an opportunity to fill the form out, and by now I was getting fairly tired of the whole thing anyway! The thing that finally got me, however, was a bill from Vitel - on the “closed” subscription - for not only the monthly fee, but also several kroner of SMS “content services” (Read: ring tones) and GPRS data (Which never even worked even when the subscription did!) So last Tuesday, June 3rd, I send them the damned fax. Wednesday, June 4th, I call NetCom up and ask what the status is of my subscription. “Oh, yes, this is now active with us.” -”Really?!” (I was happy in the way that only someone who’s gone 5 months without a working phone could be.) -”Sure, we’ve sent the SIM card to Bekkeveien (something).” -”…Bekkeveien? But I’ve never lived at any Bekkeveien. My last name is Bekkedal, but..” -”Alright, then that’s probably a mistake. What you can do, though, is go to a NetCom dealer and pick up a new SIM card.” -”Perfect! I’ll do that, then.” (I stress “pick up” for a reason which will later become apparent.) Goodie. I’ll get a working phone! I was very happy as I took the tram down to Aker Brygge and looked everywhere for the damned NetCom dealer. Having finally found it, I happily stride inside and ask for a SIM card for my subscription. “Sure. That’ll be 200 Kroner.” Argh! I hadn’t brought enough money! She did say pick up. Oh well. Aker Brygge is a center of business, I’m sure there are other shops. So I ask to use one of their phones to call NetCom. Sorry, no phones you can use. Sigh. Fine. Do you know of any phone booths around? They didn’t, but I found one anyway, finally. I deposit the necessary $1 for a local call (See, this is the problem with having a cellphone company run the phone booths!) and dial NetCom customer service. They take my number and - Sorry, that number isn’t yet active, it’s still registered to Vitel. ARGH! Fine. So what’s standing in the way? Well, Vitel can’t refuse it - (thanks, I know that already) - but the form that I was sent wasn’t the right form. The form I need to send is from Vitel to Vitel, authorizing the transfer.While I’m trying to hold a conversation with the customer support guy, some drunk guy is accusing me of stealing phones, and begins reading out loud the sponsor company names on the back of my DebConf T-shirt. But Vitel has already told me that I cannot transfer this number, under any circumstance! They consider it closed! “Yes, but you have to talk to Vitel.” -”I have!” -”Well, we can’t really do anything…” Alright. So I hang up and I try to call Vitel. But that doesn’t work: They closed at 3 PM!. So finally tired of Netcom failing to port my number for a while, I call Telenor. I talk to a very cheerful and helpful lady who admits to not knowing about the particulars of that situation. Fantastic! At least she isn’t going to fib it! She says that she has a vacation Thursday, but she can call me back on Friday after discussing the matter with the number transfers department. Wow! She’s actually going to confer with the relevant expertise! This is too good to be true! So she said she’d call me back Friday at 1PM with a status update. As I am writing, it is Friday at 11:01, I am anxiously awaiting the telephone call. But now I get a funny SMS message:

From: NetCom Message from NetCom: Your number has been ordered by another operator. We would like to remind you that violation of the commitment period will be billed to the order of 1500 kroner. For questions, call 05050.

My subscription with Vitel was made in 2006, more than the 12 months I and knowledgeable friends believe to be the maximum legal commitment period (I doubt I would have agreed to more anyway!). Besides, the text message keeps saying that it’s from NetCom. So my deduction is: It’s from NetCom, who I have registered an active subscription and are now complaining that I’ve moved the subscription I’ve opened with them (but which they have not successfully moved from Vitel), over to Telenor. I don’t think this is an unfair conclusion. So I call NetCom customer service - which to NetComs infinite credit is a number you always can call, almost like 112 (technically it’s accomplished completely differently, but you get my point. The number is never blocked in a blocked subscription.) And they say it’s not from NetCom, even though it says it’s from NetCom. So I’ll keep both of my readers posted on the developing situation. At least the text message indicates that something is happening with my subscription. I just want the dialtone!

Mom and I went to Wal-Mart today to pick up two digital converter boxes (specificlly coupon-eligible converter boxes, “CECBs”) as emergency backup for Comcast’s frequently-incompetent cable service in Memphis. It took about 15 minutes for the assorted checkout staff figured out how to ring up the converters and use the government coupons for them, but eventually we escaped with two RCA DTA800B converters. I found the box relatively easy to use and hook up. The boxes included quick start guides in English and Spanish and full user manuals in both languages, as well as a programmable remote control (with batteries) and a short push-on coax (F-type) cable for attaching the box to a TV over the “antenna” TV input. Both boxes worked moderately well in southeast Memphis with a rather lame RCA unpowered indoor VHF/UHF antenna I picked up a while back, which is no Silver Sensor but a bit more compact to haul around, less likely to attract quizzical stares from airport security, and better than nothing at all. Neither box was able to scan WMC‘s rather weak digital signal (authorized at 394 kW but clearly not transmitting at anything close to that power) and there’s no manual tuning option. I’d imagine if I’d brought a decent directional antenna like the Silver Sensor I’d have gotten WMC and a more stable signal on some of the other channels. So, overall, I have no real complaints about the boxes themselves, except for the lack of a manual tuning feature available on other converters, and the SmartAntenna feature will be nice for folks with hard-to-tune channels in multiple directions when you can actually buy one again. I’ll probably examine some of the other CECB models before settling on one, however, particularly now that it appears that the reported Zenith DTT900 audio problem is fixed in newer boxes.

I gave Brenda a Palm TX, so she can better organize her life. As a plus, it is wi-fi aware, so all sorts of interesting things can be done. Sadly, though, it doesn t ship with a microphone (I still wonder why it s large enough to hold an embedded mic, just as Palm smartphones have). Lately, Brenda was talking about recording some sessions or holding her thoughts in one of those tiny memo-recorders, and this promptly stroke me as another gadget to stuff her purse ... then I remembered having read that Palm TX have all that is required to hold a microphone, but the microphone I retrieved the Palm Multi-Connector pinout from Wikipedia and realized that all I had to do was attach an electret microphone to 16 and 17 pins and there we go. I ordered a charging cable just for the connector and here are the pictures I took of the building process: The tools and pieces I used: It s easy to disassemble the connector. Take a close look at the attaching plastic hooks there are four of them: two outside, near the pins, and two inside near the cable. Last two are harder to detach, but once you ve detached the first ones, just hold the two pieces of the connector and easily shear them: one side will detach first. The microphone have two terminals that already hold enough soldering tin. Beware to solder the blue cable (the one that goes with pin 16 AGND) to the marked terminal of the microphone, and the red one (the one that goes with pin 17 MIC_IN) to the unmarked one. (In the picture, my cables are all black, but the wires inside are red or blue . I could not get a good picture of the terminal markings). I have dissolded the charging cables from pins 1, 3, 5, and 8, but that is up to you (you can just cut the main cable and leave the pins untouched). Also, while soldering the microphone cables to the connector, beware of using as little tin as possible. It ll be even easier if you remove the pin from the connector it s easy to do if you have small pliers and careful fingers. Try first with one of the other pins that will not be used. Solder the red one to pin 17 and the blue one to pin 16. I cut a piece of an old earphone cushion to close the charging cable hole (and to protect the microphone). Here is the final result: Now, for the recording software, there s a nice free software that does that perfectly for PalmOS: Better Recorder. Now Brenda can record her mind!

Someone asked on a mailing list how to redirect output from a running process. They had a program which had been running for a long period of time without having stdout redirected to a file. They wanted to logout (to move the laptop that was used for the ssh session) but not kill the process (or lose output). Most responses were of the form “you should have used screen or nohup” which is all very well if you had planned to logout and leave it running (or even planned to have it run for a long time). Fortunately it is quite possible to redirect output of a running process. I will use cat as a trivial example but the same technique will work for most programs that do simple IO (of course programs that do terminal IO may be more tricky - but you could always redirect from the tty device of a ssh session to the tty device of a screen session). Firstly I run the command “cat > foo1” in one session and test that data from stdin is copied to the file. Then in another session I redirect the output: Firstly find the PID of the process:
$ ps aux grep cat
rjc 6760 0.0 0.0 1580 376 pts/5 S+ 15:31 0:00 cat Now check the file handles it has open:
$ ls -l /proc/6760/fd
total 3
lrwx—— 1 rjc rjc 64 Feb 27 15:32 0 -> /dev/pts/5
l-wx—— 1 rjc rjc 64 Feb 27 15:32 1 -> /tmp/foo1
lrwx—— 1 rjc rjc 64 Feb 27 15:32 2 -> /dev/pts/5 Now run GDB:
$ gdb -p 6760 /bin/cat
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc
[lots more license stuff snipped]
Attaching to program: /bin/cat, process 6760
[snip other stuff that’s not interesting now]
(gdb) p close(1)
$1 = 0
(gdb) p creat(”/tmp/foo3″, 0600)
$2 = 1
(gdb) q
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program: /bin/cat, process 6760 The “p” command in GDB will print the value of an expression, an expression can be a function to call, it can be a system call… So I execute a close() system call and pass file handle 1, then I execute a creat() system call to open a new file. The result of the creat() was 1 which means that it replaced the previous file handle. If I wanted to use the same file for stdout and stderr or if I wanted to replace a file handle with some other number then I would need to call the dup2() system call to achieve that result. For this example I chose to use creat() instead of open() because there are fewer parameter. The C macros for the flags are not usable from GDB (it doesn’t use C headers) so I would have to read header files to discover this - it’s not that hard to do so but would take more time. Note that 0600 is the octal permission for the owner having read/write access and the group and others having no access. It would also work to use 0 for that parameter and run chmod on the file later on. After that I verify the result:
ls -l /proc/6760/fd/
total 3
lrwx—— 1 rjc rjc 64 2008-02-27 15:32 0 -> /dev/pts/5
l-wx—— 1 rjc rjc 64 2008-02-27 15:32 1 -> /tmp/foo3 <====
lrwx—— 1 rjc rjc 64 2008-02-27 15:32 2 -> /dev/pts/5 Typing more data in to cat results in the file /tmp/foo3 being appended to. Update: If you want to close the original session you need to close all file handles for it, open a new device that can be the controlling tty, and then call setsid().

Share This

I was bought a pair of these for Christmas. For the past few years I've been using a pair of Hitachi TMP028s - cheap clip on headphones that I've found far better than the popular ear bud style, but nothing special. The Sennheisers are much better again. They have a neat little padded cup that means they make a good fit with your ears, the headband is reasonably adjustable (I've had issues with my glasses with other headphones) and they come with a carry case and fold flat which means throwing them in my bag for my train commute much easier. All in all I've been very impressed in my use over the past month. And then today I finally put some batteries in to power the noise cancellation function. Wow. Much more effective than I expected. I was able to knock the volume on my iAudio down a fair bit and still hear the music better than usual. The noise of the train was still present, but reduced significantly to the point where it wasn't an issue at all. Definitely recommended.

The current method of carrying young children (less than 4-6 years old) in cars is to have a special car seat fitted in the back seat. This has several significant problems:

• It takes significant space in the back seat. The child seat is going to add at least 10cm to the length required in the back seat and often drives the purchase of larger cars (including SUV and 4WD vehicles that are known for being unsafe - especially for children). Having child passengers in a car is a great distraction for the driver, driving a large vehicle increases the difficulty in avoiding accidents - especially when parking.


• The seat belts of the rear seats are used as part of the mechanism of attaching the child seat to the car. Seat belts are designed to stretch in a crash. It’s recommended that after a crash all seat belts that were used to secure people or objects be replaced as they will have stretched. Seat-belts that don’t stretch will cause more serious injuries. It seems likely to me that a seat belt used to tightly secure a child seat for a long period of time will stretch without a collision. Therefore if an older child is seated where they (or another child) used to have a child-seat then they may be at greater risk in the case of a collision.


• Child seats should be fitted by specially trained experts if they are to be safe. The majority of seats are not correctly fitted and put children at needless risk (the cost of getting an expert to do the installation is small).

Some car companies are offering child “booster seats” that are an optional attachment to the rear seat (I first noticed this when reviewing the specs of the latest version of the car I drive - the VW Passat [1]). This is a good idea, but it doesn’t go far enough. The best thing to do would be to provide a selection of back-seat assemblies as factory fitted options which have built-in baby and child seats. The combinations that would be most desired are:

1. Standard car back-seat for three adults (or two adults for a small car).


2. A regular seat (for an adult) at the road side of the car combined with a baby (backward facing) seat at the kerb side.


3. A regular seat (for an adult) at the road side with a young child (forward facing) seat at the kerb side.


4. A baby seat at the road side with a young child seat at the kerb side.


5. Two young child seats.

It would be quite possible to have all five of these options available from the factory. Of course there are corner cases that this doesn’t cover such as twins or parents who have two children so close together that they need two baby seats. For those cases option 2 combined with one of the current off-the-shelf baby seats would do. The number of different supported options would need to be kept reasonably small to reduce manufacture cost and to allow a reasonable market for second-hand seats. One thing to note is that it’s recommended that the first forward-facing seat a child uses is smaller than the later one. Having options for three different built-in baby/child seats (rear-facing and two sizes of forward-facing) would significantly expand the number of combinations (and thus the expense). I suspect that the safety benefits of having an ideal method of securing a forward-facing child seat would compensate for the disadvantage of having it be too large for the child when they are first placed in it. Another possibility would be to replace the rear seat with a more solid bench with bolt holes for baby and child seats. Securing a child or baby seat to a hard surface with bolts would be a much less technically demanding task than using a seat belt (and thus could be done correctly without expert assistance). Child and baby seats would have to be redesigned for this (I suspect that the safety of them relies on being attached to a soft surface), but after that I expect that safety would improve. For this option the rear seat could bold on to a hard surface that’s suitable for attaching child/baby seats so it would simply be a matter of removing the rear seat and installing the child/baby seat(s). The most common car design in Australia includes a 60/40 split rear seat (meaning that if you have a large item to store in the boot/trunk then you can fold down 40% or 60% of the back of the rear seat to allow the luggage to extend into the passenger compartment). This split could be extended to allow removing the base of the rear seat for 60% or 40% to bolt on child/baby seats. Once a car model had been designed for replacing the rear seat there would be other options available. For example replacing the rear seat with luggage storage space. While almost all cars allow folding down the backs of the rear seats to store extra luggage the option of removing seats that you don’t need to give even more space is not common at all (I’ve only seen it advertised as a feature in vehicles with 6 or more seats). I expect that if this idea was implemented it would allow a small car such as a Toyota Corolla to give an equal or greater amount of usable space for children in the rear as a larger vehicle such as a Toyota Camry. While better options for luggage storage would allow people who don’t have children to use a small car while still being able to carry the luggage that they desire. This would allow considerable savings on car purchase prices and fuel use. I expect that a reduction in fuel use world-wide could be achieved by removing the pressure on parents to buy large cars! The poor support for child seats in cars is really surprising. One of the features that could be introduced is both top and bottom mounts for such seats. There is apparently a standard for this, some (not all) cars support it, but most baby seats apparently don’t. So baby and child seats are secured at the top (to a hook that’s bolted securely to the car frame and which was designed specifically for the purpose) and at the bottom to the seat-belt which was never designed for such things. It’s a pity that some of the money spent on supposedly protecting children from drugs couldn’t be spent on making cars safer for them. The government is in the best position to force car manufacturers to improve their safety features while parents are in the best position to teach children about the dangers of drugs.

• [1] http://www.volkswagen.com.au/pdf/Brochures/Passat_160807.pdf

Share This

As part of my research, I may have to conduct a survey among Debian contributors. The word "survey" usually elicits frowns because surveys are often misconducted. MJ has taken the time to draft up some advice to surveyors. Problems with surveys generally fall into one of two categories: content and presentation. I'll refrain from making statements about content (Wikipedia has some stuff on questionaire construction) and instead concentrate on presentation in the following. Commonly in the digital age, surveys are administered via a web page or e-mail. In my recent Ph.D. transfer report, I identified a number of shortcomings with these approaches: Asking Debian contributors to click radio buttons on a web page is a bit like expecting a mountain biking champion to ride a tricycle across a paddock: painful, if not offensive. Furthermore, web surveys can only be taken while on-line, when most of us have better things to do. E-mail surveys address some of these problems, but create new ones: answers cannot be constrained to a domain (think multiple-choice), character set and formatting issues make evaluation difficult, and it's impossible to prevent users from attaching comments or modifying responses. In thinking about the issue, I came up with a third means to administer a survey: a console tool. Think of a Debian package which provides a console application controlled by a study-specific data file. The data file specifies the questions and their answer domains, and the tool presents those to the participant. Since most of Debian happens on the console anyway, such an approach to surveys seems more appropriate. Interaction with the survey tool would be as easy as pressing the 2 or 4 keys to select one of the multiple choices, and the tool would immediately move on to the next question (and not wait for the user to hit enter). Obviously, n and p should allow navigation back and forth across the set, and c would spawn a text editor to give the user a chance to attach a comment to his/her current response, in which s/he might criticise the question or provide additional information. Finally, the tool should be able to pick up where it left off, should the user chose to exit/suspend the survey for now. Integration with debconf or another interface abstraction is also worth consideration. There is more to it: people change their minds and should thus be able to amend responses. With their consent, it might be valuable to track such changes and inquire about their motivations. As I was thinking about how to realise this, I suddenly arrived at version control: use Git as a backend storage. The set of cool features this would enable seems to be endless: it works off-line and can be used to track aforementioned changes, but also offers the possibility to create a squashed result in case the participant prefers to submit only the final result. Furthermore, it's a trivial change between anonymous submissions, and submissions authenticated by a GPG signature. In addition, the survey tool should be able to display questions according to previous responses (control flow). For instance, if the survey determines that a given user is a contributor to the bug tracking system, but not a project member, it wouldn't make sense to ask when s/he received his/her Debian account. Furthermore, questions could be dynamically creatable from context, so that the survey can drill into depth depending on previous responses, rather than asking the same questions to all participants. I am currently applying for funding to outsource the development of such a tool. If you are interested in coding it up and getting paid for it, speak to me. Here are some more specifications to keep in mind before jumping on:

• the result must be released under a Free licence.
• the tool should be implemented in Python and use PyGit. Missing Git bindings should be implemented in and contributed to PyGit.
• the logic should be in a reusable module, and the application a thin layer on top of that.
• data files must be able to specify at least multiple-choice, Likert-scale and free-form-answer questions.
• data files should be able to encode conditional flow.
• data files should encode whether submissions can/must/mustn't be anonymous.
• data files should encode policy whether changes can/must/mustn't be tracked.
• it would be nice if data files could encode dynamic questions assembled at run-time.
• questions and answers must be translatable using standard .po files.
• in addition to the console interface, a debconf interface would be nice.
• every response results in a Git commit object, and commit messages may be automated or queried from the user, depending on context and configuration.
• data files should provide parent/seed SHA-1 hashes such that every participant essentially commits to a branch off the same parent, using e.g. uuencoded bundles.
• submission should take place via git-push or git-send-email, depending on whether a net connection exists or not.

These are likely to be incomplete, but should convey the basic picture. Feedback is always welcome! NP: Oceansize: Frames Update: James Andrewartha pointed me to purity, which asks multiple-choice questions on the console. It has the kind of interface which I envision. Also, Chris Lamb suggested this personality survey as a base line. Well, actually he just suggested I look into it.

GNU Screen rocks, in general, but recently I've been using it a lot for custom applications and have discovered a pair of annoying bugs. If you're not familiar with it then please read this GNU Screen tutorial - it really is worth getting to know! Anyway onto the bugs:

• Session names may not start with numbers.
• Session names must be globally unique.

The two are related, but I'm not yet sure whether I should report bugs against the Debian package and the code is sufficiently cryptic that I cannot create a fix yet. Taking the bugs in reverse order please try this:

screen -S foo
[detach]
screen -S foo2
[detach]

At this point you should have two screen sessions "foo" and "foo2". You should be able to attach to them by running "screen -R foo" or "screen -R foo2". Lets try that:

skx@vain:~$ screen -R foo
There are several suitable screens on:
        22317.foo       (Detached)
        22342.foo2      (Detached)
Type "screen [-d] -r [pid.]tty.host" to resume one of them.

Even though foo should be sufficient to identify a unique screen, the first one, it doesn't let you attach. Nasty. (Yes, you can attach to it if you use the number/number+name:

screen -R  22317.foo 

The second issue is related. Create a screen session with "screen -S 222". Now try to attach to it with "screen -R 222" - instead of attaching it gives you a brand new screen. Ugh.

Danny Angus writes about the potential threat posed by small storage devices with large capacity [1]. His post was prompted by a BBC article about Hitachi’s plans for new hard drives [2], they are aiming for 4TB of data on a single drive by 2011 and a 1TB laptop drive. One thing I noticed about the article is that they made the false claim that current drives are limited to 1TB, the storage capacity is determined by the total surface area which is proportional to the square of the radius and the height of the drive (AFAIK there are no practical limits to the number of platters apart from the height of the drive). So if a 5.25 inch hard drive was to be manufactured with today’s technology it should get a capacity equivalent to at least three times the capacity of the larger 3.5 inch drive. The reason that 5.25 inch drives are not manufactured is that for best performance you want multiple spindles so that multiple operations can be performed concurrently. Using 3.5 inch drives in servers allows the use of more disks for the same amount of space in the rack and the same amount of power. The latest trend is towards 2.5 inch (Small Form Factor AKA SFF) disks for servers to allow more drives for better performance. With 3.5 inch disks a 1U system was limited to 3 disks and a 2U system was often limited to 4 or 5 disks. But with 2.5 inch drives a 2U server can have 10 drives or more. I know of one hardware vendor that plans to entirely cease using 3.5 inch drives and claims that 2.5 inch disks will give better performance, capacity, and power use! In regard to Danny’s claim (which is entirely correct) about the threat posed by insiders. I don’t believe that a laptop with 1TB of capacity is the threat. In a server room people notice where laptops get connected and there are often strictly enforced policies about connecting machines that don’t belong to the company. I believe that the greatest threat is posed by USB flash devices. For example let’s consider a database with customer name (~20B), birth-date (10B), address (~80B), phone number (~12B), card type (1B), card number (16B), card expiry (5B), and card CVV code (3B). That’s ~155 bytes per record in CSV or TSV format. If you have data for a million customers that’s 155M uncompressed and probably about 50M when compressed with gzip or WinZip (depending on which platform is being ripped). No-one even sells a USB flash device that is smaller than 50M, I recently bought a 2G flash device that was physically very small and cheap (it was in the bargain bin). The next issue is, what data might be worth stealing that is large enough to not fit on a USB device? I guess that if you want to copy entire network file shares from a corporation then you would need more than the 16G that seems to be the maximum capacity of a USB device at the moment. Another theoretical possibility would be to copy the entire mail spool of a medium to large ISP. For the case of a corporate file server you could probably get the data at reasonable speed, 1TB of data would take 10,000 seconds or 2.8 hours to transfer at gigabit Ethernet speeds (if you max out a GigE link - it could be as much as five times that if the network is congested or if the server is slow). It’s doable, but it would be a rather tense three or more hours waiting by an illegally connected laptop. For the mail server of a large ISP there is often no chance of getting anywhere near line speed, it’s lots of small reads and seek performance is the bottleneck, such servers are usually running close to capacity (and trying to copy data fast would hurt performance and draw unwanted attention). Another possibility might be to copy the storage of an Intranet search device. If a company has a Google appliance or similar device indexing much of their secret data then copying the indexes would be very useful. It would allow offline searches of the corporate data to prepare a list of files to retrieve later. It would probably be more useful to get online access to the data from a remote site. I expect that an unethical person could sell remote access to someone who is out of range of extradition. All that would be required would be to intentionally leave a flaw in the security of the system. In most large corporations this could be done in a way that is impossible to prove. For example if management decrees that the Internet servers run some software that is known to be of low quality then a hostile insider could make configuration changes to increase the risk - it would look like an innocent mistake if the problem was ever discovered (the blame would entirely go to the buggy software and the person who recommended it). A large part of the solution to this problem is to hire good employees. The common checks performed grudgingly by financial companies are grossly inadequate for this. Checking whether a potential employee has a criminal record does not prevent hiring criminals, it merely prevents hiring unsuccessful criminals and people who have not yet been tempted enough! The best way to assess whether HR people are being smart about this is to ask them for an estimate of how many criminals are employed by the company. If you have a company that’s not incredibly small then it’s inevitable that some criminals will be employed. Anyone who thinks that it is possible to avoid hiring criminals simply isn’t thinking about the issues. I may write more about this issue in a future post. Another significant part of the solution to the problem is to grant minimum privileges to access data. Everyone should only be granted access to data that they need for their work so that the only people who can really compromise the company are senior managers and sys-admins, and for best security different departments or groups should have different sys-admin teams and separate server rooms. Of course this does increase the cost of doing business, and probably most managers would rather have it be cheap than secure.

• [1] http://blog.killerbees.co.uk/2007/10/all-your-data-are-belong-to-us.html


• [2] http://news.bbc.co.uk/1/hi/technology/7044606.stm

Share This

It appears that some people actually want to see Katachi in action before they try it. I can't imagine why, it only requires two libraries to be installed from version management, both of which are slightly obscure. So, here is a screenshot. Also some other people don't know where to get GVFS and GtkImageView from. This is the git tree for GVFS, and GtkImageView is here. GtkImageView 1.1.0 should work fine if you fix the trivial compile warnings, so maybe I should ditch my local SVN checkout and use the release for now.

Over the last few months I've been hacking on (yet another) image viewer for GTK+, using the hot new GVFS library (go Alex!) for asynchronous file handling and GtkImageView because I'm lazy. It's got a pretty lean interface at the moment and is fairly fast in use. My goal is to use it on my Zaurus for reviewing images from a CF card in the field, so performance is quite important to me. As the primary users are photographers, filenames are not shown in the interface (just thumbnails). There is a lot of work left to do, but I've used 0.1 for some time now. The source is being developed in a Bazaar branch at http://burtonini.com/bzr/katachi. I've just tagged a 0.1 release, a tarball of which is here. You'll need to build GVFS from git, and GtkImageView from svn, sorry. :) NP: Closes Volume 1, Boards of Canada

If you’ve received email from an attorney in the last five years, you’ve probably seen some version of a boilerplate warning/disclaimer in the message footer, indicating that the message may be privileged (or in some cases, asserting that the message is privileged!) and telling the receiver to destroy and/or return all copies if they are not the proper recipient. In the last couple of years, almost everyone has also added a statement to the effect that this email does not contain illegal tax advice (or if it does contain such advice, you shouldn’t use it!) Cumulatively, I’m sure we’ve used gigabytes if not terabytes of bandwidth attaching this text to every email sent. My question to the world: is anyone aware of such an email disclaimer ever being enforced or held enforceable?

Share This

... is NaughtySVN.

I have joined this project which was started by Alexander Thomas a few weeks ago and I have convinced him that is better to have a release sooner rather than later. The project is still in its early alpha stage[*] but I thought is better to have a rather minimalist and functional client first.
So, I talked to Alexander and we came up with a roadmap; for the 0.0.1 release I am working on the update feature which is about 40% done[1][2] (update dialog screenshot).

Of course, after the release I will probably make a debian package, too, unless someone else beats me to it :-) .

So, the future is bright.


Update: as a response to a comment, NaughtySVN is designed to be not only a Subversion client, but also a framework for other VCS-es and other clients. It just happens that we are working on the Subversion backend and client at the moment.

P.S.: as curiosity of mine, I have written in python a small nautilus plugin that does the svn update (is a svn frontend) and I must say I really miss the development speed of python when writing in C (or maybe I am out of practice).

[*] only a few features are implemented and can't be used yet as a SVN client without being forced to use another client.
[1] according to my estimations
[2] update related code is not committed yet